home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 12 / BBS in a box XII-2.iso / Files II / Prog / M / MacWT 0.04.sit / WT Docs / README < prev   
Encoding:
Text File  |  1994-05-18  |  8.9 KB  |  219 lines

  1. wt - a 3D game engine
  2.  
  3. Copyright (C) 1994 by Chris Laurel
  4.  
  5. Please see the LICENSE file for further details.  You may not distribute
  6. this project without this file (README) and the LICENSE file included.
  7.  
  8. ---------------------------------------------------------------------------
  9.  
  10. This is still a preliminary version of my 3D game engine, wt.
  11.  
  12. * In the proud tradition of cp, mv, rm, as, and cc, now there is 'wt'
  13.   wt (never capitalized) stands for "what's that?"
  14.  
  15. * This is not by any means a complete game.  It is just a demo of my
  16.   graphics engine.  I'd never name a game wt.
  17.  
  18. * wt is portable software.  See the section on porting at the end of this
  19.   README for information on what to change in order to port to another
  20.   platform.
  21.  
  22. * Features:
  23.     * Easy to edit world file.  Just haul out your favorite text editor
  24.       and modify 'castle.world'  Or create your own .world file from
  25.       scratch.  Whee.  Just don't get carried away because the world
  26.       file format will be changing before the next release.
  27.     * No BSP trees were killed to make this program.  Sorry . . . it's
  28.       late.  BSP trees are elegant and fast *if* your environment is
  29.       static.  I eventually want walls in wt that move and change shape.
  30.       However, if I can't kill a bug having to do with walls perpendicular
  31.       to the view plane, I may have to resort to a BSP tree for determining
  32.       wall visibility (or if my current algorithm is too slow for worlds
  33.       with a large number of walls.)
  34.     * Variable texture map size.  Texture maps for walls can be any
  35.       width you like, but the height must be either 64 or 128.  Floor
  36.       textures must be either 64x64 or 128x128.  The main reason why
  37.       arbitrary powers of two aren't supported has to do with the fact that
  38.           Intels x86 chips don't have enough registers for my innermost loops.
  39.     * Texture scaling for walls.  The walls have an x scale factor and
  40.       a y scale factor.  It might be more properly called 'frequency,'
  41.       since the smaller the parameter, the bigger the texture map will
  42.       appear.  Supporting the scaling factors requires a couple of extra
  43.       multiplies in the wall drawing function.
  44.  
  45.  
  46. * Running the demo (this applies to the Linux version only):
  47.     
  48.     * For xwt, just type 'xwt castle.world'  The keys are:
  49.         forward - up arrow
  50.         backward - down arrow
  51.         turn left - left arrow
  52.         turn right - right arrow
  53.         strafe - slash
  54.         run - shift
  55.         jump - space
  56.  
  57.     * To run wt, you need to be root (or make it setuid root first.)
  58.         It sucks to have to run a binary you grabbed off the net as
  59.             root, but as far as I know, that's the way it has to be with
  60.         svgalib base programs.
  61.  
  62.         As root, type 'wt castle.world'  The keys:
  63.  
  64.         forward - e
  65.         backward - x
  66.         turn left - s
  67.         turn right - d
  68.         strafe left - a
  69.         strafe right - f
  70.         jump - space
  71.  
  72.  
  73. * Responses
  74.  
  75.     * I received a lot of e-mail from people about the binary-only
  76.       version 0.01 of wt.  Thanks for all the interest, and I apologize
  77.       to anyone to whom I did not respond.  I've been frying my brain
  78.       on wt.
  79.  
  80.     * While wt does look similar in many respects to DOOM, it is not
  81.       based on any DOOM source code, and I have no connection with Id
  82.       software other than being a customer.
  83.  
  84.     * The most frequently asked question was about the texture file
  85.       format.  As you can now tell by looking at texture.[ch], it
  86.       is my own format.  There's no reason for this beyond the fact
  87.       that I wanted something for a quick prototyping of the engine,
  88.       and I didn't have any graphic file format specs sitting around.
  89.       I'm open to suggestions about texture file format.
  90.  
  91.     * I will add mouse support for the X11 and svgalib versions.  I also
  92.       want to support the Linux keyboard better by setting it to
  93.       RAW mode.
  94.  
  95.     * Your X server needs to support the MIT shared memory extension
  96.       in order for wt to run.  Also, it only currently supports an
  97.       8-bit pseudo color visual.  I just haven't had a chance to perfect
  98.       the X code.
  99.  
  100.     * I will eventually design a world editor.  It will run under X and
  101.       be based on Tcl/Tk.
  102.  
  103.     * Pitch and roll will not be supported.  It's a fundamental constraint
  104.       of the engine design.
  105.  
  106.     * Weird things will happen when you jump above the tops of buildings
  107.       or though the ceiling.  You cannot see the tops of buildings--this
  108.       is another design limitation.
  109.  
  110.     * Resizing the view window . . . this does need to be supported.  The
  111.       reason why it is not currently supported again has to do with the
  112.       limited register set of the x86 chips.  I wanted to keep all my
  113.           variables in registers in the innermost loop, but they would not
  114.       all fit.  So, I made the view width an immediate constant . . . if
  115.       I can coax gcc to let me use the ebp register, I'll use that to
  116.       hold the width.  Or I could just deal with the (probably minor)
  117.       speed degradation I'd get by reading it from memory.
  118.  
  119.  
  120. * Room for improvement
  121.  
  122.     * Better texture file format.  There's some unnecessary information
  123.       in the texture files now which is left over from a previous 3D
  124.       project.
  125.  
  126.     * Optimizations.  There are some obvious ones that I have not gotten
  127.       around to implementing yet.  In particular, the multiplies in
  128.       calc_wall_heights can be avoided.  I think that the floors code
  129.       can be sped up also.  If you know of any improvements to the
  130.       assembly loops in slice.c, *tell me*.  I'm not an Intel assembly
  131.       language guru or anything.
  132.  
  133.     * Code cleanup.  The core of wt is still in development, so some of
  134.       the code surrounding the renderer is hacky test-the-engine stuff.
  135.       Once wt starts developing into a real game, much of the code
  136.       will be reorganized.  wt.c will change completely.
  137.  
  138.  
  139. * 'Port away!'
  140.  
  141.     * wt now supports both big and little endian machines.  The only
  142.       endianness dependent part of the code was in texture.c.  If you
  143.       have a big endian machine (pretty much anything but an Intel system)
  144.       you may need to edit the makefile and add -DBIG_ENDIAN to CFLAGS.
  145.       However, my system already has an endian #define, so you may
  146.       not need to do anything.
  147.  
  148.     * There are three types of #define's used to block off non-portable
  149.       sections of the code.  ARCH_i86 surrounds the couple assembly
  150.       routines in the wt source.  I also surround these with an
  151.       #ifdef __GNUC__ because the inline assembly code syntax in
  152.       gcc is different than for other x86 compilers I've seen.  (Anyone
  153.           considering doing an DOS or Windows port take note:  the GNU
  154.       assembler uses AT&T syntax, which has the reverse operand order
  155.       of Intel syntax.)  Finally, there is a #define to identify
  156.       the graphics system.
  157.  
  158.     * Substitute C routines exist for assembly language functions.
  159.       On a RISC system with a good compiler, I figure you shouldn't need
  160.       to recode them in assembly language.  The C functions *should* work.
  161.       I have not tested them in a while, but they were used extensively
  162.       before I rewrote them in assembly.
  163.  
  164.     * Before attempting to compile on a non-UNIX system, #define PROFILE
  165.       to be zero in render.c.
  166.  
  167.     * If you've got a non-Intel system with X11 (or an Intel system
  168.           with X11 which does not have gcc), then you should be able to
  169.       compile wt successfully by just not defining ARCH_i86 in the
  170.       Makefile.
  171.  
  172.     * If you're not running X11, then you'll need to write your own
  173.       graphics and input routines and add a #define for your graphics
  174.       system.  Check out linuxvga.c and x11graphics.c for sample
  175.       graphics implementations.  All you need is an initialization
  176.       function, a cleanup function, and something to blast a framebuffer
  177.       the screen--memcpy, CopyBits or whatever . . .
  178.  
  179.     * The input system hooks are in input.c.  For sample input routines,
  180.       look in linux-console.c and x11input.c.  Mac and Windows people:
  181.       x11input.c should give you a good idea about how to tie an
  182.       event handler into wt.
  183.  
  184.     * Send me your ports and I'll include them in the next wt distribution!
  185.       This goes for other improvements to wt, too.  Although I love
  186.       hearing ideas, I'm *not* building a game yet.  I'm just interested
  187.       in getting the engine working cleanly and quickly on as many
  188.       platforms as possible.
  189.  
  190.     * I'm especially interested in reports about how fast wt will run
  191.       on different platforms (wtStones?)  If you do a port, talk to me
  192.       about speed, especially if you have a PowerMac or Alpha system.
  193.       If you port it to a 286, I'm interested but I might laugh.
  194.  
  195.     
  196. * Future directions:
  197.  
  198.     * I'd like to see wt become a multi-platform client for an
  199.       Internet wide MUD type game.  Or a perhaps a net-wide arcade
  200.       game like Xpilot.  I've got a lot of other more innovative ideas
  201.       but I'd better get the engine done before I start spouting about
  202.       them.
  203.  
  204. * CREDITS
  205.  
  206.     Dan Egnor (egnor@ugcs.caltech.edu) - submitted the first set of
  207.          endian fixes.
  208.     Dave Thomas (dave@thomases.demon.co.uk) - wrote up an Imakefile
  209.  
  210. * Me:
  211.  
  212.     send any comments, ideas, bug reports, etc. to:
  213.  
  214.     Chris Laurel
  215.     home: claurel@mr.net
  216.     work: chrisl@county.lmt.mn.org
  217.     snailmail: 5700 W Lake St, #208
  218.                    St. Louis Park, MN  55416
  219.